Exploring TM1 - a Chartertech Company
Search
Close this search box.

Dimensions in TM1

Dimensions are one of the fundamental building blocks in TM1. We put dimensions together to create cubes and then cubes to hold data.

What are Dimensions?

Dimensions in TM1 are just structured lists of elements (or sometimes known as members). So a list of product, months, customers, measures, years, accounts, cost centres, WBS codes, versions, people and so on. A list usually has structure, so we will roll months up into quarters, quarters to half years and half years to All Months. Or, for a product dimension, we might roll the actual SKUs we sell up into product categories, then product groups and then maybe to All Products.

Elements

Elements (or members) are the individual items that make up dimensions. So in the month dimension mentioned above, we might have Jan, Feb, Mar, Apr, May etc as elements. We might also then have a consolidated element for All Months, which might have First Half and Second Half rolling up to it. They might, in turn, have Q1, Q2, Q3 and Q4, all also consolidated elements, as children. Which in turn have the individual months rolling up to those. So in this example, we end up with four levels of the dimension:

  • All Months
  • Half Years
  • Quarters
  • Months

We will normally want to use an ID from another system as the primary way of describing an element. For example, if we have a product dimension, we will probably use product ID’s, or SKU’s, from our ERP system.

Elements can be for populating values, for entering text or for rolling up, or consolidating, values. Note that if you do have a text (or string) element, it must be structurally the last dimension in a cube.

Numeric data is always entered into the bottom level elements (known as “leaf”, or sometimes “N level” elements) in a dimension and then is rolled up through the consolidation elements. Strings can be entered at any level of a dimension as clearly, they don’t roll up!

Attributes of Elements

Attributes are ways for us to describe elements. Normally an attribute will be describe a facet of the element. For example, on a customer dimension, you might have a channel attribute, or an industry attribute. If we think of an account dimension, we would probably want to have an attribute that shows the name of the account. Likewise, for a month dimension, we might want to have a long description, so Dec has a long description attribute of December and maybe a numeric attribute with the number 12 in it, for the twelvth month. On the product dimension we might then have a description attribute that holds the name of the product, noting that the name might change over time (and thus we would not want to use the name as the primary element ID).

Attributes can be text, numbers or aliases.

You can have as many attributes as you like and they can be populated from other systems (like an ERP), or loaded from text files or manually entered by users.

Attributes in a Planning Analytics dimension

Aliases in TM1 Dimensions

Aliases are special attributes that must be unique. We use aliases for referring explicitly to an element in reports, forms, rules and processes, where we want to use something other than the primary ID (note that it is not necessarily good practice to use aliases in rules and processes though because they can, by their nature, change and that would bugger up the rule or process).

So if you have that product dimension from above with SKU’s as the primary way of identifying an element and a description attribute, we can’t be sure that the description will always be unique. So often we will concatenate the ID with the description to create a unique string that can be stored in the alias. Then we could use that alias in reports and forms, confident that it is a unique identifier and will only return data for that element. The screenshot below shows the ID-Name alias in use in the product dimension.

Alias on the Product Dimension in TM1

Sets and Subsets in Dimensions

Same thing. Two names. Sets are synonymous with Subsets. But what are they. What they are is on the can – a set of the elements from a dimension. So for our customer dimension, we might have a set of all the elements from a particular industry. Or, from our month dimension, we might have a set of all the leaf (“n”) level elements.

Sets allow us to use specific groups of elements in reports, forms, when manipulating data and so on.

They can also be automatically managed using MDX, so they can be always maintained as complete sets, even when there are new elements.

Hierarchies

Hierarchies in TM1 used to be just a word for describing structures built with input level and consolidation elements in a dimension. Now the word “hierarchy” has a specific meaning in Planning Analytics where we can have multiple hierarchies in a dimension. If enabled, all dimensions have at least one hierarchy. We would now normally have a single rollup structure inside a hierarchy, whereas prior to formally having a container called hierarchies, we could have multiple alternate rollup structures in a dimension, making it potentially very complex.

Virtual Hierarchies

Virtual hierarchies are used to create dynamic rollup structures based on the contents of an attribute. They can then be used as separate axis for analysis. For example, if you have a continuous time dimension with month and year concatenated to form elements, then for, say a three year horizon, you might have 12 months x 3 years plus 3 annual totals and a consolidation of all the years, for 40 elements in the dimension. If we then had a Month and Year attributes, we could populate the Month with just the three character month Jan, Feb, Mar etc and the Year with 2023, 2024 and 2025. We could then present months and All Months as columns and years and All Years as rows for a 52 cell cross tab. Very clever!

Levels

One of the other nice features of Planning Analytics is the inclusion of levels. They allow us to describe all the elements of a hierarchy. For example, in our product dimension, we had All Products, Product Category, Product Group and SKU – four levels. We can name those levels and make those names available for users to make selection and analysis easier.

Need Help?

Want to know more about dimensions, attributes, aliases, virtual dimensions and so on? Just ping us your question and we’ll be delighted to help out.

  • This field is for validation purposes and should be left unchanged.
  • This field is for validation purposes and should be left unchanged.

Post Sections

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Log In